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SUMMARY 

Development  of  the  right  applications  software  for  the  water  industry  that  is  robust, 
flexible,  maintainable,  and  portable  requires  a  strategy  that  determines  user  needs,  creates 
software  in  a  develop,  test,  user  feedback  process,  and  includes  training  and  support.  Software 
engineering  decisions  related  to  the  choice  of  engineering  methodologies,  program  architecture, 
coding  languages,  graphics  and  other  support  libraries,  and  adoption  of  hardware  and  software 
industry  standards  are  critical  to  success.  Development  of  engineering  applications  software  is 
best  accomplished  by  organizations  with  experience  in  both  the  problem  addressed  and  software 
development  and  support. 

1.  INTRODUCTION 

Applications  software  are  important  tools  used  by  the  water  resources  community  for 
planning,  design  and  operation  of  water  resource  projects.  Desktop  hardware,  operating  systems, 
coding  languages,  and  a  myriad  of  other  factors  Imve  evolved  such  that  the  traditional  applications 
development  environment  of  an  engineer  writing  FORTRAN  code  is  no  longer  appropriate.  The 
software  used  in  the  coming  decade  will  be  highly  sophisticated  from  a  technical  standpoint, 
constructed  specifically  for  the  user  environment,  and  include  advanced  graphical  display 
capabilities. 

There  are  several  important  questions  for  the  water  engineering  community  to  address. 
What  should  the  software  do?  How  and  in  which  environment  should  it  function?  How  should 
this  be  determined?  Who  should  develop  this  software?  Who  (and  how)  should  support  the 
software?  How  can  the  profession  ensure  that  user  needs  will  be  adequately  reflected?  The 
answers  to  these  questions  are  of  Interest  because  a  new  generation  of  applications  software  is 
under  development  by  governments,  academia,  and  the  commercial  sector.  This  paper  summarizes 
"truisms”  related  to  engineering  software  development  and  technology  transfer  and  offers 
commentary  related  to  these  questions. 

2.  A  PROVEN  SOFTWARE  DEVELOPMENT  STRATEGY 

A  method  for  successfully  accomplishing  software  development,  implementation  and 
servicing  is  as  follows:  a)  need  for  new  methods  and  procedures  surface  through  solving  real- 
world  problems  and  maintaining  contacts  with  the  user  community,  b)  research  and  development 
work  is  performed  to  solve  specific  problems,  c)  solutions  are  generalized  so  that  they  may 
service  other  problems,  d)  high  quality  documentation  is  developed  and  software  is  prepared  for 
long  term  service  and  maintenance,  e)  training  courses  are  held  and  consultation  projects 
performed  that  gradually,  but  systematically,  move  the  software  into  every  day  work  of  users,  and 
0  continuing  development,  servicing  and  maintenance  are  performed  to  assure  aid  to  users  and 
guarantee  up-to-date  capabilities  are  incorporated. 

2.1  Observations  for  Applications  Package  Developers 

Several  "truisms”  have  emerged  that  are  applicable  to  the  development  and  implementation 
of  engineering  applications  packages.  These  observations  are  directed  to  a  unit  in  an  institution 
(public  or  private)  that  is  developing  new  applications  software  and  provides  service  and  support 
to  in-house  and  other  users. 

a)  Large  scale,  complex,  comprehensive  computer  programs  are  dynamic  entities  that 
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require  continuous  nurturing  and  support  in  order  to  remain  viable  and  useful.  Such  computer 
software  needs  a  permanent  home;  an  institution  that  is  philosophically  committed  to  the 
improvement  in  procedures,  morally  committed  to  servicing  and  improving  the  programs, 
competently  staffed  to  perform  that  task,  and  available  ”on  call*  to  users. 

b)  Professionally  developed  computer  program  code  and  its  management  is  vital  for 
software  to  be  effectively  maintained  and  be  portable  among  hardware  platforms.  Use  of  special 
purpose  languages  that  are  proprietary  or  are  not  generally  within  platform  and  software  industry 
standards  should  be  avoided.  Adherence  to  "standards*  such  as  American  National  Standards 
Institute  (ANSI)  language  standards  is  important  and  use  of  modern  programming  practice  is 
needed  to  minimize  difficulties  in  computer  source  code  maintenance. 

c)  Successful  implementation  of  advanced  applications  packages  requires  both  useful 
technology  available  in  appropriate  form  and  users  that  are  interested  and  anxious  to  take 
advantage  of  the  opportunities.  It  is  important  in  early  stages  to  encourage  applications  that  are 
manageable  and  have  potential  for  success.  A  commitment  to  a  service  attitude  and  genuine 
interest  in  solving  user  community  specific  problems  are  basic. 

A  series  of  do’s  and  do  not’s  with  supporting  explanation  follows  which  attempts  do  define 
a  framework  and  strategy  for  applications  software  development  and  implementation. 

a)  Engineering  management  should  not  "require*  applications  packages  to  be  used  before 
considerable  experience  and  shake-down  is  accomplished.  Nothing  kills  interest  in  a  new  package 
like  forced  use  that  does  not  deliver  the  solution  to  everyone’s  problems.  New  applications 
packages  can  not  be  so  tightly  developed  that  they  can  survive  an  environment  wherein  the 
potential  users  are  put  in  a  negative  posture  by  the  forced  approach.  A  pragmatic,  steady,  gradual 
introduction  will  likely  result  in  early,  meaningful  xise  of  the  concepts  and  techniques.  Nothing 
draws  users  like  success,  no  matter  how  small. 

b)  Avoid  (if  possible)  the  grand  "demonstration*  exercise.  Application  demonstrations 
designed  to  sell  technology  often  get  too  many  people  involved  with  parochial  agendas.  The 
exercise  often  becomes  rigged  or  fails  because  of  the  weight  of  so  many  observers.  Dissemination 
of  basic  information  through  publicizing  applications  is  useful.  Including  sessions  on  the 
application  in  seminars,  genei^  meetings,  and  training  courses  is  an  excellent  method  for  exposing 
applications  packages  to  potential  users. 

c)  Work  With  users  to  solve  their  problems.  A  full  commitment  to  solving  the  users 
problem  is  perhaps  the  single  most  important  facet  of  successful  technology  transfer.  An 
approach  that  solves  specific  problems  from  which  the  elements  are  continuously  merged  into  an 
analytical  system  is  more  responsive  to  user  needs  than  creating  a  grand  solution  that  is  then 
adapted  to  a  specific  problem.  It  is  not  unusual  for  an  application  to  have  some  unique  twist. 
Early  implementation  efforts  should  seek  to  work  with  users  on  specific  studies. 

d)  Carefully  select  manageable  studies  or  portions  of  studies  for  initial  applications.  This 
is  the  operational  implementation  of  the  idea  that  nothing  draws  users  like  success,  no  matter  how 
small.  The  selection  of  small  well-defined  problems  that  both  developers  and  users  can  learn  from 
and  thus  improve  the  program  is  important.  A  poor  strategy  attempts  to  "solve  the  unsolvable*  as 
an  early  application.  There  are  always  difficult  problem;  needing  solution;  build  an  experience 
base  before  stretching  too  far.  A  series  of  small,  growing  to  more  comprehensive  and  ^ficult 
applications  over  time  is  the  desired  strategy. 

e)  Be  prepared  and  willing  to  perform  logic  and  program  code  changes  for  early  studies. 
Developers  usually  can  not  foresee  all  potential  study  environments,  objectives,  data  availability, 
issues,  etc.  for  which  the  software  might  be  used.  I^ign  deficiencies,  bugs,  and  errors  will  exist. 
The  attitude  and  ready  resources  to  make  the  necessary  adjustments  will  reflect  the  commitment 
to  a  services  approach  to  implementation. 


2.2  Observations  for  Applications  Package  Users 

The  successful  user  is  one  that  is  confronted  with  a  problem,  has  struggled  to  find  a 
solution,  and  recognizes  that  it  could  be  at  least  partially  addressed  with  the  applications  package. 
The  unsuccessful  user  is  often  the  recipient  of  an  applications  package  provided  by  a  colleague  or 
superior.  The  colleague  or  superior  was  probably  introduced  to  the  software  in  a  general  way  and 
be<»me  convinced  that  it  must  surely  have  value,  especially  if  appropriately  used  by  others,  (the 
user)  to  solve  his  problems.  With  these  positions  defined,  a  few  comments  are  offered  below. 

a)  Know  problems  and  needs  in  detail.  There  is  a  tendency  for  users,  especially  those 
who  are  not  highly  computer  oriented,  to  end  up  with  their  problems  becoming  defined  by  the 
performance  capabilities  of  a  particular  software  package.  This  results  in  a  reverse  approach  to 
acquiring  a  high  technology  solution  to  a  problem  and  is  usually  not  the  best  approach. 

b)  Determine  how  the  problem  should  be  solved  irrespective  of  the  capabilities  of 
applications  pack^es.  Sophisticated  applications  packages  require  considerable  commitment  of 
resources,  both  dollars  and  manpower.  The  potential  user  should  make  certain  that  resources  are 
effectively  used  to  accomplish  the  problem  solution  that  generated  the  search  for  the  applications 
package. 

c)  Thoroughly  investigate  features  and  capabilities  of  alternative  applications  packages. 
Applications  packages  come  in  integrated  hardware-software  arrangements,  software  ^one,  or 
just  specific-task  oriented  software.  Important  issues  are  propriety  of  the  package  (Is  a  license 
required  and  what  are  the  costs  ^d  restrictions?),  speciali^d  namre  of  hardware  platforms  and 
peripherals,  software  package  adherence  to  standards,  documentation,  service,  training,  and 
compatibility  with  existing  and  future  equipment  and  people.  What  is  right  for  one  circumstance 
may  not  be  relevant  to  another. 

d)  Do  not  expect  magic.  Applications  packages  performance  between  hardware  and 
system  environments  can  vary  greatly.  While  one  should  prudently  seek  a  package  that  has  a 
record  of  minimum  difficulties,  it  is  best  to  plan  for  at  least  some  start-up  time  and  remain 
flexible.  Startrup  should  be  well  planned  and  involve  user  representatives. 

e)  Willingly  commit  the  personnel  resources  to  "own”  the  applications  package.  A  major 
shortcoming  in  the  effective  use  of  sophisticated  applications  packages  is  the  unwillingness  of 
potential  users  to  devote  adequate  time  and  energy  to  "own"  the  software  package  in  an 
applications  sense.  Most  capable  engineering  applications  packages  are  sufficiently  sophisticated 
that  continuous  use  and  familiarity  by  the  users  is  needed  to  maintain  effectiveness. 

f)  Continuously  ask  questions  of  the  developers  and  user  supporters.  Probe  the  limits  of 
capabilities,  and  presume  sophisticated  software  should  be  continually  adapted  and  improved  over 
time.  A  package  frozen  in  capability  from  installation  date  is  one  that  will  soon  be  unresponsive 
to  the  needs  of  the  users.  When  evaluating  and  using  engineering  products,  it  is  of  primary 
importance  that  the  user  truly  understand  the  product.  A  first-rate  engineer  that  truly  knows 
wluit  he  is  doing  will  likely  produce  a  better  solution  using  a  second-rate  applications  product, 
than  a  second-rate  engineer  could  do  using  a  first-rate  applications  product  he  doesn’t  understand 
well. 

3.  DEVELOPING  THE  RIGHT  APPLICATIONS  PACKAGE 

Determining  user  needs  is  the  critical  first  step  in  the  development  of  a  successful 
applications  package.  Software  engineering,  a  discipline  that  addresses  the  complete  software 
development  cycle,  continues  to  propose,  test,  and  refine  strategies  for  ensuring  successful 
software  development  projects.  A  popular  software  engineering  approach  often  referred  to  as  the 
"waterfall  model"  includes  performing  the  following:  requirements  analysis,  preliminary  and  final 
design,  coding,  testing,  deployment,  and  service  and  support.  The  process  is  conceived  of  as  once 
through,  beginning  to  end,  permitting  an  efficient,  manageable,  production  oriented  approach. 


Users  define  the  needs  and  software  specialists  design,  code,  test,  and  deploy  the  product.  Some 
interaction  with  users  is  anticipated  during  the  development  process. 

Experience  suggests  that  while  this  ^proach  is  a  useful  framework,  development  of 
successful  engineering  applications  software  is  best  served  by  a  less  formally  structured,  multi¬ 
pass  approach.  The  organization  and  its  staff  that  is  assigned  the  development  project  is 
important.  Organizations  and  staff  that  have  experience  in  performing  studies  in  the  technical 
area  of  interest,  developing  and  deploying  applications  packages,  and  training  and  support  are  best 
suited  to  performing  the  work. 

The  requirements  analysis  step  is  useful  and  essential.  Preliminary  requirements  are 
defined  by  a  development  team  in  consultation  with  a  selected  group  of  user  representatives.  The 
preliminary  requirements  are  documented  and  circulated  among  a  Wger  user  group  for  comments 
and  input.  Fii^  requirements  are  then  prepared  by  the  developers  in  consultation  with  the 
selected  group  of  users.  Development  of  a  prototype  (or  limited-scope  preliminary  version)  can 
be  very  helpful  at  this  stage  by  providing  a  real,  functioning  program  (as  compart  to  a  paper 
plan)  to  which  potential  users  may  respond.  A  certain  amount  of  design  will  ^ve  taken  place 
during  the  prototype  development.  Its  best  to  take  time  to  perform  a  complete  conceptual  design 
that  will  be  tested  in  the  prototype  development.  Flexibility  for  future  improvements  key. 

Development  of  the  applications  package  can  then  be  undertaken  as  a  production  process. 
For  a  sophisticated  and  capable  engineering  applications  package,  the  development  team  should  be 
compris^  of  a  specialist  in  the  technical  applications  area  (often  the  team  leader),  and  a 
complement  of  computer  scientists,  programmers,  and  consultants.  In  today’s  technology 
environment,  the  development  of  an  engineering  tq>plications  product  requires  the  combined 
talents  of  knowledgeable  engineer-practitioners  and  skilled  computer  science  specialists.  It  is  no 
longer  possible  for  a  few  engineers  to  possess  the  broad  range  of  skills  necessary  to  produce  a 
satisfactory  product  Not  all  team  members  need  to  be  full-time  on  the  project.  The  consultants 
may  be  from  other  groups  in  the  organization  or  procured  via  contract  to  provide  limited  scope, 
highly  specialized  knowledge  that  is  essential  in  the  extremely  capability-rich  yet  complex 
hardware  and  systems  environment. 

Development  should  be  staged  so  that  usable  products  emerge  in  a  regular  manner 
throughout  the  development  period.  Product  releases  should  be  often  enough  to  provide  the  user 
community  with  the  opportunity  to  observe  progress  and  provide  feedback  on  n^ed  capabilities, 
but  not  so  often  as  to  create  a  climate  of  turmoil  and  distraction  for  the  developers.  Six-month 
intervals  is  probably  too  short  with  one-year  intervals  about  right.  The  first  release  after  the 
prototype  should  be  a  preliminary  yet  fully  functional  package.  Early  releases  should  be  to 
selected  users  that  are  willing  to  apply  the  package  to  real  problems  but  who  are  familiar  with 
software  development  so  that  difficulties  that  will  arise  are  not  unexpected. 

4.  HARDWARE,  OPERATING  SYSTEM,  CODING,  AND  RELATED  STANDARDS 

Today  the  typical  engineering  computing  environment  has  become  the  desktop  machine. 

It  is  likely  to  be  a  high-end  personal  computer  with  an  Intel  486  processor  (soon  to  be  succeeded 
by  PS),  or  a  RlSC-chip  based  engineering  workstation  (or  X-Terminal  to  a  workstation)  equipped 
with  a  high  resolution  color  monitor.  The  desktop  machine  is  connected  to  other  workstations, 
file  servers,  laser  printers,  plotters  and  other  devices  via  a  local  area  network.  In  some  instances, 
access  to  regional  centers  and  other  national  and  international  sites  is  available  through  network 
gateways  to  world-wide  communication  facilities. 

The  software  developer  must  design  and  develop  applications  packages  to  take  advantage 
of  the  opportunities  provided  by  this  rich  environment.  Developers  must  be  careful  to  avoid 
constructing  applications  that  exhibit  hardware  and  system  dependencies  that  adversely  affect 
code  portability,  future  upgrades,  and  long-term  servicing.  Most  software  industry  professionals 
and  users  generally  agree  that  these  notions  are  highly  desirable;  the  goals  are  easy  to  articulate. 
The  pay-off  is  in  the  successful  translation  into  software  development  strategies,  standards. 


criteria,  and  ultimately  computer  code  that  achieves  those  goals. 

4.1  Hardware/operating  System 

Hardware  and  associated  "chip*  families,  operating  systems,  and  binary  (compiled  and 
linked)  code  compatibility  are  tightly  connected.  For  example,  MS-DOS  [1]  and  Microsoft 
Windows  [2]  operate  within  the  Intel-chip  family  of  personal  computers  and  thus  binary  code  is 
compatible  among  machines.  There  are  a  variety  of  RISC  chips  ttot  are  used  in  workstations. 
Binary  code  is  generally  compatible  within  a  chip  family  (vendor  product  line);  for  example 
among  the  IBM  RISC-chip  workstation  line  of  computers,  but  not  across  chip/vendor  computers. 
UNIX  [3]  is  the  standard  operating  system  for  RISC-chip  engineering  workstations  providing  code 
compatibility  at  the  source  (not  binary)  level.  While  this  is  not  particularly  important  for  the  user, 
it  is  extremely  important  for  program  developers. 

Minimum  hardware  configuration  and  specifications  that  can  be  expected  for  the 
engineering  desktop  for  the  next  few  years  are  as  follows: 

Personal  Computer  Intel  486/66  mhz  processor,  8  to  32  MB  RAM,  200  to  600  MB  disk, 
14”  Super  VGA  monitor,  networked  to  plotters  and  printers,  DOS/Windows  operating 
environment. 


Workstation:  RISC-chip/SO  mips  processor,  32  MB  RAM,  1  gigabyte  disk,  17*  monitor, 
networked  to  other  workstations  and  peripherals  locally  and  regioi^ly,  UNIX  operating 
system. 

For  the  personal  computer,  DOS  has  been  the  unquestioned  standard  for  office  automation 
applications.  While  there  are  a  number  of  capable  engineering  applications  packages  running  in 
DOS,  the  future  seems  to  be  toward  multi-tasking,  window-based  systems.  Candidates  are 
Microsoft  Windows  (soon  to  be  Windows  NT  [4J),  OS/2  Presentation  Manager  [5],  and  UNIX.  In 
the  RISC-chip  based  workstation  environment,  UNIX  is  the  standard,  with  the  possibility  that 
Windows  NT  might  soon  be  a  competitor  for  some  chip  families.  It  is  important  to  maintain 
adherence  to  a  standard,  such  as  Posix  [6]  to  ensure  cross  UNIX  platform  compatibility. 

For  the  software  developer,  the  issue  is  therefore  what  hardware  configuration,  likely 
operating  systems,  coding  languages  and  associated  compilers,  third-party  libraries,  etc.  will 
enable  the  desired  performance,  portability,  upward  compatibility,  and  service  support  needed  for 
the  applications  package.  The  likelihood  is  that  packages  will  ne^  to  be  functional  in  both 
environments.  The  appropriate  strategy  to  follow  is  to  code  the  application  using  languages, 
libraries,  utilities  etc.  that  make  it  least  painful  to  port  to  other  pbtforms.  This  is  easier  said  than 
done. 

4.2  Programming  Philosophy,  Languages,  and  Related  Issues 

The  application  package  to  be  developed  must  ultimately  be  coded  in  a  computer  language, 
compiled,  and  linked  into  binary  code  for  execution  on  a  specific  platform.  Various  prognunming 
strategies,  languages,  and  use  of  commercial  utilities  and  libraries  are  employed.  Historically, 
engineering  applications  programs  were  developed  by  an  engineer  programming  in  FORTRAN 
and  following  the  ANSI  language  standard.  Often  the  program  in  current  use  was  originally  coded 
in  FORTRAN  11,  with  subsequent  improvements  coded  in  FORTRAN  IV,  66,  and  77  and  ported 
and  re-compiled  for  the  successor  generation  platforms.  This  continued  to  be  successful  and 
relatively  simple  while  programs  read  mostly  number  and  character  input  and  output  the  same. 

The  base  engineering  functions  that  implement  the  solution  algorithms  are  becoming  more 
and  more  transportable  across  a  wide  variety  of  chip  families.  This  is  true  whether  they  are  coded 
in  FORTRAN,  C  [7],  or  another  popular  language.  Data  base  access,  graphical  user  interfaces 
(GUI),  and  visualization  tend  to  inhibit  transportability  across  platforms  at  the  current  time.  New 


languages  have  emerged  responsive  to  the  needs,  and  an  impressive  array  of  commercial  libraries 
and  higher  level  coding  aides  are  available  to  be  used  by  the  programmer.  While  no  definitive 
consensus  has  emerged,  there  are  a  number  of  logical  strategies  to  consider  in  programming  the 
^plications  package. 

The  graphical  user  interface  is  the  boon  and  the  bane  of  the  programmer.  It  offers  the 
opportunity  to  create  a  comfortable  and  highly  productive  user  environment.  The  developer  must 
be  careful,  however,  to  avoid  dressing  up  a  poor  or  outdated  engineering  solution  with  an 
attractive  user  interface.  The  engineering  algorithms  must  be  top-notch  in  order  to  warrant  the 
considerable  effort  to  create  a  productive  GUI. 

Most  recently  developed  GUI  are  code^  in  C  using  standard  Motif  [8]  and  X  Windows  [9] 
library  functions  because  of  the  platform  portability  and  power  in  providing  direct  programmer 
control  of  the  user-device  interface.  A  programming  concept  referred  to  as  object-oriented 
programming  (OOP)  [10]  is  emerging  as  an  important  player  in  the  user  interface,  as  well  as 
other,  programming  areas.  It*s  reported  power  is  that  of  enabling  the  creation  and  mamoulation 
of  reusable  coded  objects  that  can  substantially  improve  the  robustness  and  maintainability  of  the 
software  and  productivity  of  the  programmer.  The  coding  language  that  is  gaining  a  following  for 
implementation  of  OOP  is  C-h-  [11].  A  number  of  major  commercial  software  vendors  are 
reported  to  have  adopted  C-h-  for  their  own  new  program  development.  Motif  and  Open  Look 

[12]  provide  widget  libraries  that  prescribe  a  standard  look  and  feel  for  constructing  GUI’s  in  the 
X  Window  system.  X  Windows  is  the  de  facto  standard  windowing  system  for  the  UNIX 
operating  system.  In  the  DOS  environment,  Microsoft  Windows  is  dominant  with  IBM  OS/2 
Plantation  Manager  also  a  player. 

Unfortunately,  a  GUI  developed  following  standards  in  the  UNIX  workstation 
environment  is  not  directly  portable  to  Microsoft  Windows,  and  vice  versa.  Since  engineering 
applications  packages  will  most  likely  need  to  function  in  both  systems,  a  dilemma  exists.  One 
approach  is  to  develop  separate  GUTs  for  each  environment.  W^e  unattractive,  its  done  in  the 
commercial  sector.  Another  is  to  use  proprietary  GUI  builder  libraries  and  cross  platform 
compilers.  This  is  also  unattractive,  perlmps  even  more  so.  The  best  approach  seems  to  be  to 
proceed  with  development  following  the  prevailing  standard  in  each  (say  Motif  and  Microsoft 
Windows),  isolate  the  code  related  to  the  GUI  from  other  program  functions,  and  take  care  to  be 
as  consistent  between  both  environments  as  possible.  One  also  hopes  that  the  next  few  years 
continues  the  trend  toward  a  common  operating  system  and  attendant  GUI  standards  tlmt  will 
serve  both  environments. 

The  majority  (perhaps  above  90%)  of  currently  used  engineering  applications  program 
"engines*,  the  engineering  algorithm  solution  portion  of  the  program,  are  coded  in  FORTRAN. 
This  is  likely  to  continue  for  some  time  for  new  programs  as  well.  Tliis  is  both  because 
engineering  programs  tend  to  be  developed  by  engineers,  and  routines  from  the  substantial 
inventory  of  functioning  FORTRAN  programs  will  be  re-used  in  new  programs.  FORTRAN  90 

[13] ,  the  next  ANSI  FORTRAN  standard,  offers  new  data  structures,  dynamic  memory,  and  other 
desirable  attributes.  Some  industry  observers  have  suggested  that  future  FORTRAN  standards 
and  extensions  will  implement  OOP  concepts  more  fully.  A  number  of  software  development 
projects  [14],  are  being  developed  with  OOP  concepts  using  C-h  for  the  overall  program 
architecture,  C  where  necessary,  and  FORTRAN  for  some  compute  functions. 

4.3  Graphics 

Increasing  use  of  display  and  output  graphics  (often  referred  to  as  visualization)  is  the 
emphasis  for  the  future  for  engineering  applications  packages.  Coding  the  graphics  routines  using 
primitive,  basic  level  intrinsics  from  libraries  may  be  logical  and  practical  for  mass  market 
commercial  software  firms.  It  is  not  often  practical  for  the  more  limited  market  of  engineering 
applications  programs.  Making  calls  from  Ae  applications  program  to  graphics  functions  routines 
is  more  common.  The  question  then  is  which  package  of  graphic  function  routines  should  be 
used?  Again,  the  circumstance  is  complicated  so  the  best  choice  is  not  obvious. 


The  choices  reduce  to  selecting  from  commercial  and  public  domain  packages  (there  are 
quite  a  number)  such  as  UNIRAS  [IS]  and  Interviews  [16]  that  provide  graphics  products  on-the- 
fly  from  simple  program  level  calls.  Decision  factors  include  capability,  licensing  and  fee 
arrangements,  documentation  and  support,  platform  availability,  and  success  history  in  the  market 
place.  All  th^gs  being  equal,  one  would  select  the  package  that  has  adequate  capability,  is  in  the 
public  domain  thus  minimizing  licensing  and  f^  issues,  is  available  for  target  workstation  and 
personal  computer  platforms,  and  is  reasonably  documented  and  supported. 

No  package  has  emerged  that  has  gained  significant  market  acceptance  that  supports  both 
workstation  and  personal  computer  platforms.  If  the  application  will  be  run  only  in  the  Microsoft 
Windows  environment  and  the  Windows  graphics  library  is  adequate,  it  is  an  attractive  choice. 

This  is  not  often  the  case  but  in  the  near  term,  it  may  be  a  reasonable  alternative  for  the  personal 
computer  implementation  of  the  applications  package.  The  use  of  X  Windows  libraries  provide 
such  capabilities  in  the  UNIX  environment.  No  clearly  dominant  commercial  or  public  domain 
high-level  graphics  support  package  has  emerged  for  programming  ^plications  for  either 
Microsoft  windows  or  X  Windows  workstations.  It  is  desirable  that  products  be  developed  such 
that  they  may  interface  to  still-higher  level  graphics  capabilities  available  in  geographic 
information  systems  packages. 

4.4  Data  Base  Support 

An  important  issue  for  software  development  projects  is  providing  for  data  persistence 
necessary  to  support  the  GUI,  graphics,  and  technical  analysis  envisioned.  Depending  on  the 
applications  package,  many  data  types  must  be  addressed.  These  could  include  time-series, 
(hydrologic  data),  paired-function  (x,y  tabulations),  model-parameter,  stream-geometry,  and 
spatial  and  image  data.  Data  base  management  systems  were  created  to  meet  such  needs.  The 
larger,  more  complex  in  scope  the  applications  package,  the  more  likely  that  significant  amounts 
of  data  of  several  types  might  be  important.  No  single  data  base  system,  commercial  or  private, 
seems  to  offer  efficient  management  for  the  full  range  of  data  types.  Commercial  systems,  for 
example  ORACLE  [17],  offer  great  capability  for  managing  relational  data,  but  limited  capability 
for  time  series  data.  Specialized  systems,  for  example  HEC-DSS  [18],  are  optimized  for  time- 
series  and  paired-function  data. 

Developers  should  carefully  analyze  the  data  management  needs  for  their  specific 
applications  package,  and  design  early,  the  appro^h  to  be  taken.  The  increasing  availability  of 
industry-wide  and  regional  data  bases  that  may  be  useful  for  application  packages  warrants 
consideration  in  program  design.  Also,  the  need  to  share  (or  pass  to  the  next  step  in  design), 
engineering  data  is  an  issue  that  should  be  considered  as  well.  Whether  to  design  a  custom-coding 
solution,  or  choose  from  commercial  and  public  domain  data  base  packages  is  a  decision  that 
should  consider  portability,  license  and  run-time  fees,  programmer  effort  to  implement,  and 
requirement  for  long  term  service  and  support. 

5.  CONCLUSIONS 

Successful  development  of  the  right  engineering  applications  software  packages  requires 
adopting  a  strategy  that  determines  user  needs,  and  accomplishes  development  in  a  develop,  test, 
user  feedback  process.  Application  package  development  should  be  performed  by  organizations 
that  have  experience  in  solving  engineering  problems  in  the  field,  experience  in  developing, 
deploying,  maintaining  and  supporting  applications  software,  and  are  committed  to  a  services 
approach  to  users.  The  development  team  should  be  comprised  of  a  technical  specialist  in  the 
applications  area,  and  a  complement  of  computer  scientists  and  programmers.  The  engineering 
desktop  platforms  for  the  next  few  years  includes  high-end  Intel-chip  personal  computers  and 
RISC-chip  based  workstations.  Use  of  modem  software  architecture  concepts  to  include  OOP, 
application  of  standard  programming  languages,  and  adherence  to  published  software  standards 
(where  they  exist)  and  de-facto  industry  standards  is  essential  to  ensure  successful  applications 
package  development. 
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